But doesn't that mean that you can redeploy as often in slot 0 as TXs fit inside the block?
Not that it matters much, just saying.

But doesn't that mean that you can redeploy as often in slot 0 as TXs fit inside the block? Not that it matters much, just saying.

Once it's deployed, the state.slot will not be 0 (unless deployed in slot 0 itself). So the other condition will take over.
So yes, in slot 0 it can be deployed multiple times.

We can change it to an Option. That should be able to differentiate between initial value and value after deployment. Wdyt?

Codecov Report

Merging #33583 (bf08e79) into master (c588f25) will decrease coverage by 0.1%.
The diff coverage is 100.0%.

@@            Coverage Diff            @@
##           master   #33583     +/-   ##
=========================================
- Coverage    81.7%    81.7%   -0.1%     
=========================================
  Files         807      807             
  Lines      218283   218283             
=========================================
- Hits       178485   178464     -21     
- Misses      39798    39819     +21     

But doesn't that mean that you can redeploy as often in slot 0 as TXs fit inside the block? Not that it matters much, just saying.

Once it's deployed, the state.slot will not be 0 (unless deployed in slot 0 itself). So the other condition will take over. So yes, in slot 0 it can be deployed multiple times.

We can change it to an Option. That should be able to differentiate between initial value and value after deployment. Wdyt?

@Lichtso I thought some more about using an Option for the slot. It's doable but will complicate the logic for computing LoaderV4State from the program's account data. It might be better to keep the current logic with the caveat of special casing of the slot 0.